- Security Assertion Markup Language (SAML)
- Okta
- Microsoft Entra ID
To begin, we will configure Entra ID as the identity provider responsible for authentication. Before proceeding, it is crucial to set up a break-glass account. This account will serve as a backup in emergencies. For more details on the importance of break-glass accounts and access, please refer to the following link: https://www.strongdm.com/blog/break-glass
Here are the steps in Okta to configure this account: Directory > People > Add person
We will then add the new user to the 'Super Administrator' role: User > Admin roles > Edit individual assignments > Role > Super Administrator > Save Changes
We will now proceed with adding Entra ID as an identity provider, following the steps outlined in the following Okta documentation:
https://help.okta.com/en-us/content/topics/provisioning/azure/azure-identify-identity-provider.htm
Navigate to the following path: Security > Identity Providers > Add identity provider > SAML 2.0 IdP
We will now configure SAML 2.0 using the following settings:
Ensure to record the following values, as they will be necessary for the next steps: 'Assertion Consumer Service URL' and 'Audience URI'.
We will now create an Okta enterprise app in Entra ID, facilitating communication between Azure and Okta. For guidance, I will refer to the following Okta documentation:
https://help.okta.com/en-us/content/topics/provisioning/azure/azure-create-enterprise-app.htm
Begin by navigating to the Azure portal and to the following location: Microsoft Entra ID > Enterprise applications > New application > Create your own application.
Once application has been created, navigate to 'Set up single sign on' and 'SAML':
In the ‘Basic SAML Configuration’ section, enter placeholder URLs for ‘Identifier’ and ‘Reply URL’, and proceed to save the configuration. Select 'Download for Certificate (Base64)' in the SAML Signing Certificate area to download the certificate to your computer, which will be required for the next steps.
SAML claims are pieces of information about a user that are shared between different systems to help with logging in and accessing services, such as their name or email address. We will be editing our attributes and claims, which is essentially what information we want to send to Okta for authentication.
In addition to the default claims, we will add 'company name' and 'telephone number':
Return back to Okta, and navigate to SAML Certifications > Edit > New Certificate. Enter the following values to update the placeholders: the 'IdP Issuer URI' is the 'Microsoft Entra Identifier', the 'IdP Single Sign-On URL' is the 'Login URL', and the 'IdP Signature Certificate' is the 'Base64 download'.
Be sure to make note of the values above. The 'Assertion Consumer Service URL' will be the 'Reply URL in Azure', and the 'Audience URI' will be the 'Identity Entity ID' in Azure.
In Entra ID, update the placeholder values:
Back in Okta, navigate to: Edit profile and mappings > Mappings. We will then unmap all attributes except 'username'.
We will then navigate to 'Custom', and proceed to delete and recreate the attributes. For the attribute mapping, I will be referencing the following Okta documentation: https://help.okta.com/en-us/content/topics/provisioning/azure/azure-map-attributes.htm. Once the attributes are created, we will proceed with updating the mappings:
We will test the authentication by first navigating to our Okta application in Entra ID and assigning users to the application: Manage > users and groups > Add user/group
We are now ready to test the authentication! Navigate to Single sign-on > Test.
For advanced testing and troubleshooting, you may optionally download the 'My Apps Secure Sign-in Extension' Chrome extension. As demonstrated below, we successfully authenticated!
This involves establishing a secure communication link between Azure and Okta through the creation of an Okta enterprise application in Entra ID. The integration involves the setup of SAML claims, which define and map user attributes such as name, email, company name, and telephone number. These claims are fundamental in identifying and authenticating users across both systems. The final step in the implementation is thorough testing and validation to confirm that users can successfully log in to Okta applications using their Entra ID credentials.
Implementing federation between Azure and Okta offers significant benefits such as enhancing user experience by enabling Single Sign-On (SSO), allowing users to log in once and access multiple systems without repeated authentication. This streamlines the process and reduces the frustration of managing multiple passwords. From an administrative perspective, federation simplifies centralized management of user identities and access rights, reducing the overhead for IT teams.
Federation is particularly valuable in several use cases such as for organizations operating in hybrid environments, where a mix of on-premises and cloud-based resources needs unified access management. It also facilitates secure cross-organizational collaboration, allowing external partners to access shared resources using their own identity systems. As companies expand their IT infrastructure, federation supports scalable identity solutions by seamlessly integrating multiple identity providers.
Additionally, it aids in regulatory compliance by offering a centralized, auditable log of user access across all systems. Key terms like federation, SAML, identity provider, attributes and claims, and break-glass accounts play crucial roles in understanding this project. By combining the strengths of Microsoft Entra ID and Okta through federation, this project creates a unified and efficient identity management solution that simplifies and secures user access to diverse systems.